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IN THE SPECIFICATION: 

Please replace the paragraph [0011] 

FIG. 1 is a conceptual representation of a content management architecture. 
Content can be distributed to clients from either origin servers, e.g. 161 , 162, or 
from clusters of edge servers, e.g. 151, 152, ... 155 in a network 100 . It is 
advantageous to have a content manager 110 which is able to selectively pre- 
populate some of the edge servers with content based on various factors, such 
as a negotiated service agreement, load, the particular service type, other 
policies, etc. In particular, for example, for high-quality streaming of media, it is 
desirable not to have all of the content populating all of the edge server clusters. 
In this type of environment it becomes crucial for a client to connect to an edge 
server that already has the content it is requesting. The present invention is 
directed to various mechanisms which facilitate effective content management. 



Please replace the paragraph [0018] 

FIG. 3 and 4 illustrate the two different methods of redirection. FIG. 3 is a 
conceptual representation of a network 300 using media redirection utilizing a 
protocol-level redirect, specifically in the context of the RTSP protocol. At step 

301, a media client 380 has a URL, e.g. B rtsp://sr.target25.com/clip.rm n . At step 

302, the domain name system 311 resolves the domain name "sr.target25.com" 
to any of the streaming redirect servers 320. At step 303, the media client 280 
380 connects to the chosen streaming redirect server 320 with the URL 
"rtsp://sr.target25.com/clip.rm". At step 304, the streaming redirect server 320 
decides on an "appropriate" content server for this request, for example 
redirecting the client to an edge server 351 or 352. with the URL 
"rtsp://mec10.att.net/att/clip.rm". The IP address of the edge server 351 or 352 
can be utilized to prevent a DNS lookup. Then at step 305, the media client 380 
connects to the media edge cluster stream the desired content. The media edge 
cluster 351 or 352 may already have the content in a cache or may obtain the 
content from a media origin server 361 or 362 . 
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Please replace paragraph [0020] 

FIG. 4 is a conceptual representation of a network 400 using content redirection 
utilizing a dynamic helper file. At step 401 , a user utilizing a web client 490 
selects a media clip from a web page on a web server 495. The web server 495, 
at step 402, dynamically generates a helper file (e.g., a ".ram" or ".asx" file) with 
the appropriate URL, e.g., "mms://mec10.att.net/clip.asf. At step 403, the web 
client 490 invokes the media player 485, which contacts the domain name 
system 411 a* step 404 to feseJves resolve "mec10.att.net". Alternatively, the 
URL could be expressed with an IP address to avoid the DNS lookup. Then, at 
step 405, the media player 485 connects to a media edge cluster 451 or 452 . to 
stream the desired content. The media edge cluster 451 or 452 may already 
have the content in a cache or may obtain the content from a media origin server 
461 or 462 . 



Page 3 



PAGE 7(10 * RCVD AT 1/28/2005 8:26:08 PM [Eastern Standard Time] ■ SVR:USPTO-EFXRF-1/1 * DNIS:8729306 ■ CSID:732 530 9808 • DURATION (mm-ss):04-14 



